packages/core/src/Popper/PopperContent.vue (1)

177-182: New dir prop wiring looks correct.

dir?: Direction is optional and correctly typed against the shared Direction alias. Pairing with useDirection(computed(() => props.dir)) at Line 233 properly falls back to ConfigProvider’s direction and finally 'ltr', preserving existing behavior for unset props.

One small note: the phrasing “when applicable” in the JSDoc is a bit vague — consider clarifying that the direction only affects the computed transform-origin (specifically the start/end alignment on top/bottom placements when the arrow is hidden), and does not automatically flip side. Users in RTL layouts who want side: 'right' to visually appear on the logical start still need to mirror side themselves.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/core/src/Popper/PopperContent.vue` around lines 177 - 182, Update
the JSDoc for the dir prop in PopperContent.vue to explicitly state that dir?:
Direction (wired to useDirection(computed(() => props.dir))) only affects
computed transform-origin (i.e., start/end alignment on top/bottom placements
when the arrow is hidden) and does not flip or remap the side prop — users must
mirror side themselves in RTL; make the wording concise and replace "when
applicable" with this specific behavior.

packages/core/src/Popper/utils.ts (1)

14-18: ⚡ Quick win

Consider documenting the default direction behavior.

The dir parameter is optional, and when omitted the code defaults to LTR behavior (since options.dir === 'rtl' evaluates to false when dir is undefined). This implicit default is reasonable but not self-documenting.

📝 Suggested improvement

Consider either:

1. Adding a JSDoc comment documenting that dir defaults to LTR when omitted, or
2. Making the default explicit:

 export function transformOrigin(options: {
   arrowWidth: number
   arrowHeight: number
   dir?: Direction
 }): Middleware {
+  const dir = options.dir ?? 'ltr'
   return {
     name: 'transformOrigin',
     options,
     fn(data) {
       const { placement, rects, middlewareData } = data

       const cannotCenterArrow = middlewareData.arrow?.centerOffset !== 0
       const isArrowHidden = cannotCenterArrow
       const arrowWidth = isArrowHidden ? 0 : options.arrowWidth
       const arrowHeight = isArrowHidden ? 0 : options.arrowHeight

       const [placedSide, placedAlign] = getSideAndAlignFromPlacement(placement)
       const noArrowAlignX = {
-        start: options.dir === 'rtl' ? '100%' : '0%',
+        start: dir === 'rtl' ? '100%' : '0%',
         center: '50%',
-        end: options.dir === 'rtl' ? '0%' : '100%',
+        end: dir === 'rtl' ? '0%' : '100%',
       }[placedAlign]

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/core/src/Popper/utils.ts` around lines 14 - 18, The transformOrigin
middleware accepts an optional dir on the options object but silently treats
undefined as LTR; update transformOrigin to make the default explicit and/or
document it: either (a) add a JSDoc above the transformOrigin function stating
"dir defaults to 'ltr' when omitted" and mention how it's used, or (b) normalize
the value inside transformOrigin by assigning a default (e.g., const dir =
options.dir ?? 'ltr') before any checks (references: transformOrigin and
options.dir) so the LTR default is obvious and maintained.

packages/core/src/Popper/Popper.test.ts (1)

68-110: 💤 Low value

Consider adding a test for default dir behavior.

The current tests verify that explicitly passing dir='rtl' or dir='ltr' correctly sets the wrapper attribute. Consider adding a test case for when dir is omitted to document the expected default behavior.

🧪 Example test for default behavior

it('uses default dir when not explicitly provided', async () => {
  const DefaultPopper = defineComponent({
    setup() {
      return () =>
        h(PopperRoot, null, {
          default: () => [
            h(PopperAnchor, null, { default: () => 'Anchor' }),
            h(PopperContent, {}, { default: () => 'Content' }),
          ],
        })
    },
  })

  const wrapper = mount(DefaultPopper, { attachTo: document.body })
  const wrapperDiv = wrapper.find('[data-reka-popper-content-wrapper]')
  // Document expected default - likely 'ltr' based on useDirection behavior
  expect(wrapperDiv.attributes('dir')).toBeDefined()
})

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/core/src/Popper/Popper.test.ts` around lines 68 - 110, Add a test to
verify the default dir behavior when PopperContent is rendered without a dir
prop: create a component similar to RtlPopper/LtrPopper that renders PopperRoot
with PopperAnchor and PopperContent (no dir prop), mount it, find the element
with data-reka-popper-content-wrapper, and assert the wrapper's dir attribute is
set (or equals the expected default like 'ltr'); reference the existing test
helpers and components PopperRoot, PopperAnchor, PopperContent and the selector
[data-reka-popper-content-wrapper] to locate the element.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/core/src/Popper/Popper.test.ts (1)

108-130: ⚡ Quick win

Consider adding edge case: arrow data with centerOffset !== 0.

The current tests cover two scenarios:

1. No arrow data (arrowData undefined) → isArrowHidden = true
2. Arrow data with centerOffset: 0 → isArrowHidden = false

The upstream transformOrigin logic has a third path: arrow data exists but centerOffset !== 0, which sets isArrowHidden = true. While this likely behaves the same as scenario 1, testing it explicitly would verify that the no-arrow alignment (direction-aware noArrowAlignX) is correctly applied when the arrow cannot be centered.

🧪 Example test case

it('centerOffset !== 0 triggers no-arrow alignment (direction-aware)', async () => {
  const withArrow = { arrowWidth: 10, arrowHeight: 5 }
  const cannotCenter = { x: 20, y: 15, centerOffset: 5 } // non-zero offset
  
  // Should use noArrowAlignX, not arrow center
  expect((await run({ ...withArrow, dir: 'rtl' }, 'bottom-start', cannotCenter)).x).toBe('100%')
  expect((await run({ ...withArrow, dir: 'ltr' }, 'bottom-start', cannotCenter)).x).toBe('0%')
})

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/core/src/Popper/Popper.test.ts` around lines 108 - 130, Add a test
that covers the arrow-data-but-not-centerable branch: create cannotCenter = { x:
20, y: 15, centerOffset: 5 } and reuse withArrow = { arrowWidth: 10,
arrowHeight: 5 }, call run({ ...withArrow, dir: 'rtl' }, 'bottom-start',
cannotCenter) and run(..., 'bottom-start', cannotCenter) with dir: 'ltr', and
assert the returned .x uses the no-arrow alignment values ('100%' for rtl, '0%'
for ltr) to ensure the transformOrigin/arrow-centering logic (the run helper and
transformOrigin path that checks centerOffset and isArrowHidden) behaves as
expected.